Subject: Issues in latest spec (NetBIOS etc)

From: "Steve Klein" <[email-masked]>
Date: Wed, 31 Aug 94 20:20:07 EDT

Reference: Note from: Paul Brittain dated Wed, 3 Aug 94 18:30:11 BST

Paul: my comments to the third part of your note are denoted with an SCK>>>>>.

Connect RIGleteers: Please post any other comments this week if you want
                    any influence on the consensus for this items.

SPEC COMMENTS
=============
     .
     .
SCK>>>>> Everything up to 4.2.2.2 looks good.
     .
Page 50 - 51:

4.2.2.2 RESOLVE_PENDING State

      +----------------------+---------------------+----------------------+
      |        Event         |      Action(s)      |      Next State      |
      +----------------------+---------------------+----------------------+
      | Receive DATAFRAME    | DLC_DGRM            |                      |
      +----------------------+---------------------+----------------------+
      | DLC_DL_STARTED       | Send ICANREACH      | CIRCUIT_PENDING      |
      +----------------------+---------------------+----------------------+
      | DLC_ERROR            |                     | DISCONNECTED         |
      +----------------------+---------------------+----------------------+
   3  | DLC_DGRM             | Send DATAFRAME      |                      |
      +----------------------+---------------------+----------------------+

PJB>*  This state should also handle the XPORT_FAILURE event - otherwise the
PJB>*  circuit may get to CIRCUIT_PENDING state having ignored such a failure.
SCK>>>>> I agree.
PJB>*
PJB>*  I also think that we need Wayne Taylor's proposed change to add LF size
PJB>*  policing logic to this state.
SCK>>>>> Appears in version 012

   The RESOLVE_PENDING state is entered upon receipt of a CANUREACH message or a
   NETBIOS_NQ message by the target DLS.  In the former case, a data link is
   started, causing a Test command to be sent by the DLC.  In the later case, a
   NB_Name_Query frame is sent.  This frame is directed to a group MAC address.

   Any CANUREACH messages received in the RESOLVE_PENDING state will be responde
   to if a DLC_DL_STARTED signal is received.  The Data Link Switch may also
   update its topology information based upon the origin MAC address information
   in each CANUREACH message.

   Upon the receipt of a DLC_DL_STARTED signal in the RESOLVE_PENDING state, the
   Data Link Switch may update its topology table base upon the remote MAC addre
   information.  The ICANREACH message should be returned to all Data Link
   Switches that had sent a CANUREACH message.  In a similar fashion, the Data
PJB>*
PJB>* The CANUREACH_cs is a circuit setup message.  There should only be one
PJB>* such message received by any one target DLSw since the CANUREACH_ex
PJB>* exchange identifies the correct DLS partner.  Hence there is no need to
PJB>* maintain a list of partners that sent us a CANUREACH_cs as there will be
PJB>* only one.
PJB>*
PJB>* The previous sentence should therefore be deleted.
SCK>>>>> I disagree.  You still could have two separate DLSw'es
SCK>>>>> on the same LAN as the origin station attempting to initiate
SCK>>>>> a circuit through the same DLSw partner.

   Link Switch may update its topology table upon the receipt of a
   NB_Name_Recognized frame and a NETBIOS_NR message will be returned to all Dat
   Link Switches that have sent a NETBIOS_NQ message.

PJB>*  Ditto for NETBIOS_NQ_cs messages (if they survive).  This would not hold
PJB>*  for NQ_ex mesages though.
SCK>>>>> I agree that any mention of NETBIOS_NQ_cs messages should
SCK>>>>> not appear in the standard.  I will be posting comments on
SCK>>>>> version 012 that include cleaning up the commentary associated
SCK>>>>> with each table of the FSM.

   The RESOLVE_PENDING state is exited once the data link has been started (i.e.
   a DLC_DL_STARTED signal is received as a result of a Test response received b
   the DLC) or a NB_Name_Recognized frame is received (i.e., a DLC_DGRM signal i
   received).  The target Data Link Switch will then enter the CIRCUIT_PENDING
   state.

     Note:  Some implentations will also send a Test command in order to start t
     data link to the station that responded to the Name Query frame (i.e., a
     DLC_START_DL will be issued).

Page 52:

4.2.2.3. CIRCUIT_START State
   3
   3  +----------------------+---------------------+----------------------+
   3  |        Event         |      Action(s)      |      Next State      |
   3  +----------------------+---------------------+----------------------+
   3  | Receive CANUREACH_cs | If origin MAC addr  | If DLC_START_DL      |
   3  | for circuit in       | in CANUREACH_cs is  | issued:              |
   3  | opposite direction   | greater than origin |   RESOLVE_PENDING    |
   3  |                      | MAC addr of circuit:|                      |
   3  |                      |   DLC_START_DL      |                      |
   3  |                      | else:               |                      |
   3  |                      |   no action taken   |                      |
   3  +----------------------+---------------------+----------------------+
   3  | Receive ICANREACH_cs | Send REACH_ACK,     | If Connected:        |
   3  |                      | If Connected:       |  CONNECT_PENDING,    |
   3  |                      |  Send CONTACT       | else:                |
   3  |                      | else:               |  CIRCUIT_ESTABLISHED |
   3  |                      |  no action taken    |                      |
   3  |                      |                     |                      |
   3  +----------------------+---------------------+----------------------+
   3  | DLC_DGRM             | Send DATAFRAME      |                      |
   3  +----------------------+---------------------+----------------------+
   3  | CS_TIMER_EXP         |                     | DISCONNECTED         |
   3  +----------------------+---------------------+----------------------+

PJB>*  This table requires the XPORT_FAILURE event too.
PJB>*
PJB>*  I also think that we need Wayne Taylor's proposed change to add LF size
PJB>*  policing logic to this state.
SCK>>>>> XPORT_FAILURE should be added here too.  The LF stuff already
SCK>>>>> appears in version 012.

Page 58:

4.2.2.9 CIRCUIT_RESTART State

      +----------------------+---------------------+----------------------+
      |        Event         |      Action(s)      |      Next State      |
      +----------------------+---------------------+----------------------+
      | Receive DL_RESTARTED | If Connected:       | If Connected:        |
      |                      |  Send CONTACT       |  CONNECT_PENDING,    |
      |                      |                     | else:                |
      |                      |                     |  CIRCUIT_ESTABLISHED |
      +----------------------+---------------------+----------------------+
   1  | Receive HALT_DL_NOACK| DLC_HALT_DL         | HALT_PENDING_NOACK   |
      +----------------------+---------------------+----------------------+
      | Receive DATAFRAME    | DLC_DGRM            |                      |
      +----------------------+---------------------+----------------------+
      | DLC_ERROR            | Send HALT_DL        | DISCONNECT_PENDING   |
      +----------------------+---------------------+----------------------+
      | DLC_DGRM             | Send DATAFRAME      |                      |
      +----------------------+---------------------+----------------------+
   3  | XPORT_FAILURE        | DLC_HALT_DL         | HALT_PENDING_NOACK   |
      +----------------------+---------------------+----------------------+

   The CIRCUIT_RESTART state is entered if a DLC_RESET signal is received from t
   local DLC.  This was caused by the receipt of a SABME command while a
   connection was currently active.  A DM response will be issued to the SABME
   command and the Data Link Switch will attempt to restart the end-to- end
   circuit.

PJB>*  Surely a DGRMFRAME would be more sensible to use in this state as we
PJB>*  still have the circuit correlators needed for this message.
PJB>*
PJB>*  (Apologies if I have asked this before and forgotten the result - I am
PJB>*   concentrating on getting a comprehensive set of comments for discussion
PJB>*   at this point).
SCK>>>>> You are not the first to me mention this.  Unless there are any
SCK>>>>> objections we can change DATAFRAME to DGRMFRAME.

Page 60:

4.2.2.11. RESTART_PENDING State

      +----------------------+---------------------+----------------------+
      |        Event         |      Action(s)      |      Next State      |
      +----------------------+---------------------+----------------------+
   1  | Receive HALT_DL_NOACK|                     | HALT_PENDING_NOACK   |
      +----------------------+---------------------+----------------------+
      | Receive DATAFRAME    | DLC_DGRM            |                      |
      +----------------------+---------------------+----------------------+
      | DLC_DL_HALTED        | Send DL_RESTARTED   | CIRCUIT_ESTABLISHED  |
      +----------------------+---------------------+----------------------+
      | DLC_ERROR            | Send HALT_DL        | DISCONNECT_PENDING   |
      +----------------------+---------------------+----------------------+
      | DLC_DGRM             | Send DATAFRAME      |                      |
      +----------------------+---------------------+----------------------+
   3  | XPORT_FAILURE        | DLC_HALT_DL         | HALT_PENDING_NOACK   |
      +----------------------+---------------------+----------------------+

PJB>*  As before, isn't a DGRMFRAME more sensible to use in this state as we
PJB>*  still have the circuit correlators needed for this message?
PJB>*
SCK>>>>> I say we change DATAFRAME to DGRMFRAME here also.

                      -------------------------------------